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The SPaCIFY project, which aims at bringing advances in MDE to the satellite flight software indus- 
try, advocates a top-down approach built on a domain-specific modeling language named Synoptic. 
In line with previous approaches to real-time modeling such as Statecharts and Simulink, Synoptic 
features hierarchical decomposition of application and control modules in synchronous block dia- 
grams and state machines. Its semantics is described in the polychronous model of computation, 
which is that of the synchronous language SIGNAL. 



1 Introduction 



In collaboration with major European manufacturers, the SPaCIFY project aims at bringing advances in 
MDE to the satellite flight software industry. It focuses on software development and maintenance phases 
of satellite lifecycle. The project advocates a top-down approach built on a Domain-Specific Modeling 
Language (DSML) named Synoptic. The aim of Synoptic is to support all aspects of embedded flight- 
software design. As such, Synoptic consists of heterogeneous modeling and programming principles 
defined in collaboration with the industrial partners and end users of the SPaCIFY project. 

Used as the central modeling language of the SPaCIFY model driven engineering process, Synoptic 
allows to describe different layers of abstraction: at the highest level, the software architecture models the 
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functional decomposition of the flight software. This is mapped to a dynamic architecture which defines 
the thread structure of the software. It consists of a set of threads, where each thread is characterized by 
properties such as its frequency, its priority and its activation pattern (periodic, sporadic). 

A mapping establishes a correspondence between the software and the dynamic architecture, by 
specifying which blocks are executed by which threads. At the lowest level, the hardware architecture 
permits to define devices (processors, sensors, actuators, busses) and their properties. 

Finally, mappings describe the correspondence between the dynamic and hardware architecture on 
the one hand, by specifying which threads are executed by which processor, and describe a correspon- 
dence between the software and hardware architecture on the other hand, by specifying which data is 
carried by which bus for instance. Figure [T] depicts these layers and mappings. 
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Figure 1: Global view: layers and architecture mappings 

The aim is to synthesize as much of this mapping as possible, for example by appealing to internal or 
external schedulers. However, to allow for human intervention, it is possible to give a fine-grained map- 
ping, thus overriding or bypassing machine-generated schedules. Anyway, consistency of the resulting 
dynamic architecture is verified by the SPaCIFY tool suite, based on the properties of the software and 
dynamic model. 

At each step of the development process, it is also useful to model different abstraction levels of the 
system under design inside a same layer (functional, dynamic or hardware architecture). Synoptic offers 
this capability by providing an incremental design framework and refinement features. 

To summarize, Synoptic deals with data-flow diagrams, mode automata, blocks, components, dy- 
namic and hardware architecture, mapping and timing. 

The functional part of the Synoptic language allows to model software architecture. The correspond- 
ing sub-language is well adapted to model synchronous islands and to specify interaction points between 
these islands and the middleware platform using the concept of external variables. 

Synchronous islands and middleware form a Globally Asynchronous and Locally Synchronous (GALS) 
system. 

Software architecture The development of the Synoptic software architecture language has been 
tightly coordinated with the definition of the GeneAuto language [1]. Synoptic uses essentially two 
types of modules, called blocks in Synoptic, which can be mutually nested: data-flow diagrams and 
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mode automata. Nesting favors a hierarchical design and enables viewing the description at different 
levels of detail. 

By embedding blocks in the states of state machines, one can elegantly model operational modes: 
each state represents a mode, and transitions correspond to mode changes. In each mode, the system may 
be composed of other sub-blocks or have different connection patterns among components. 

Apart from structural and behavioral aspects, the Synoptic software architecture language allows to 
define temporal properties of blocks. For instance, a block can be parameterized with a frequency and a 
worst case execution time which are taken into account in the mapping onto the dynamic architecture. 

Synoptic is equipped with an assertion language that allows to state desired properties of the model 
under development. We are mainly interested in properties that permit to express, for example, coherence 
of the modes ("if component X is in mode ml, then component Y is in mode m2" or ". . . can eventually 
move into mode m2"). Specific transformations extract these properties and pass them to the verification 
tools. 

The main purpose of this paper is to describe a formal semantics of Synoptic, expressed in terms 
of the synchronous language SIGNAL 0I2]. SIGNAL is based on "synchronized data- flow" (flows with 
synchronization): a process is a set of equations on elementary flows describing both data and control. 
The SIGNAL formal model provides the capability to describe systems with several clocks {polychronous 
systems) as relational specifications. A brief overview of the abstract syntax of Synoptic is provided in 
Section [2] Then Section [3] describes the interpretation of each one of these constructions in the model of 
the Signal language. 

2 An overview of Synoptic 

Blocks are the main structuring elements of Synoptic. A block block xA defines a functional unit of 
compilation and of execution that can be called from many contexts and with different modes in the 
system under design. A block x encapsulates a functionality A that may consist of sub-blocks, automata 
and data-flows. A block x is implicity associated with two signals x.trigger and x. reset. The signal 
x.trigger starts the execution of A. The specification A may then operate at its own pace until the next 
x.trigger is signaled. The signal x. reset is delivered to x at some x.trigger and forces A to reset its state 
and variables to initial values. 

{blocks) A,B::= blockxA | dataflow xA | automaton xA | A \B 

Data-flows inter-connect blocks with data and events (e.g. trigger and reset signals). A flow can 
simpliy define a connection from an event x to an event y, written event x — >■ y, combine data y and z 
by a simple operation / to form the flow x, written data yfz — > x or feed a signal y back to x, written 
data y $init v — > x. In a feedback loop, the signal x is initially defined by xo = v. Then, at each occurrence 
n > of the signal y, it takes its previous value x n = y n -\. The execution of a data-flow is controlled by 
its parent clock. A data-flow simultaneously executes each connection it is composed of every time it is 
triggered by its parent block. 

{dataflow) A,B ::= data j$initv — >• x | data yfz —> x | event x — >• y \ A \B 

Actions are sequences of operations on variables that are performed during the execution of automata. 
An assignment x = yfz, defines the new value of the variable x from the current values of y and z by the 
function /. The skip stores the new values of variables that have been defined before it, so that they 
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become current past it. The conditional ifxthenAelsei? executes A if the current value of x is true and 
executes B otherwise. A sequence A;B executes A and then B. 

(action) A,B::= skip | x = yfz | ifxthenAelsefi | A;B 

Automata schedule the execution of operations and blocks by performing timely guarded transitions. 
An automaton receives control from its trigger and reset signals x.trigger and x. reset as specified by its 
parent block. When an automaton is first triggered, or when it is reset, its starts execution from its initial 
state, specified as initial stateS. On any state S : doA, it performs the action A. From this state, it may 
perform an immediate transition to new state T, written S — > onx T, if the value of the current variable 
x is true. It may also perform a delayed transition to T, written S -^°" x T, that waits the next trigger 
before to resume execution (in state T). If no transition condition applies, it then waits the next trigger 
and resumes execution in state S. States and transitions are composed as A | B. The timed execution of 
an automaton combines the behavior of an action or a data-flow. The execution of a delayed transition or 
of a stutter is controlled by an occurrence of the parent trigger signal (as for a data-flow). The execution 
of an immediate transition is performed without waiting for a trigger or a reset (as for an action). 

(automaton) A,B ::= stated : doA | S — > onjr T \ S ^> onx T \ A\B 

3 Polychronous interpretation of Synoptic 

The model of computation on which Synoptic relies is that of the polychronous data-flow language 
Signal. This section describes how Synoptic programs are interpreted into this core language. 

3.1 A brief introduction to S ignal 

In Signal, a process P consists of the composition of simultaneous equations x = f(y,z) over signals 
x,y,z- A delay equation x = y$\ nit v defines x every time y is present. Initially, x is defined by the value v, 
and then, it is defined by the previous value of y. A sampling equation x = y when z defines x by y when z 
is true. Finally, a merge equation x = y default? defines x by y when y is present and by z otherwise. An 
equation x = yfz can use a boolean or arithmetic operator / to define all of the n th values of the signal x 
by the result of the application of / to the n th values of the signals y and z. The synchronous composition 
of processes P \ Q consists of the simultaneous solution of the equations in P and in Q. It is commutative 
and associative. The process P/x restricts the signal x to the lexical scope of P. 

P,Q::=x = yfz\P/x\P\Q (process) 

In SIGNAL, the presence of a value along a signal x is an expression noted "x. It is true when x is present. 
Otherwise, it is absent. Specific processes and operators are defined in Signal to manipulate clocks 
explicitly. We only use the simplest one, x" =y, that synchronizes all occurrences of the signals x and y. 

3.2 Interpretation of blocks 

The execution of a block is driven by the trigger t of its parent block. The block resynchronizes with 
that trigger every time, itself or one of its sub-blocks, makes an explicit reference to time (e.g. a skip for 
an action or a delayed transition S -» T for an automaton). Otherwise, the elapse of time is sensed from 
outside the block, whose operations (e.g., on cf), are perceived as belonging to the same period as within 
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[?,-,? !+ 1 [. The interpretation implements this feature by encoding actions and automata using static single 
assignment. As a result, and from within a block, every non-time-consuming sequence of actions A,B or 
transitions A — > B defines the value of all its variables once and defines intermediate ones in the flow of 
its execution. 

3.3 Interpretation of data-flow 

Data- flows are structurally similar to SIGNAL programs and equally combined using synchronous com- 
position. The interpretation [[A]]" = ((f)) of a data-flow (Fig. [2]) is parameterized by the reset and trigger 
signals of the parent block and returns a process P (the input term A and the output term P are marked by 
[[A]] and ((P)) for convenience). A delayed flow data y $initv — > x initially defines x by the value v. It is 
reset to that value every time the reset signal r occurs. Otherwise, it takes the previous value of y in time. 



[[dataflow fAf 


=«ttAfl(lW)* A =0» 


[[data j$initv-^x]] rf 


= ((jc = (vwhenr) default (y$\ nit v) | (jc* =y)} 


[[datay/z^xf 


= ((x = yfz)) ^ 


[[event j ->x]] rt 


= ((x = wheny)) 


[[A\Bf 


=«[[A]npr» 



Figure 2: Interpretation of data-flow connections 

In Fig. [2j we write Y\i< n Pi for a finite product of processes P\ \ ...P n . Similarly, V;<n e ; is a finite 
merge e\ default . ..e n . 

A functional flow data yfz —> x defines x by the product of (y,z) by /. An event flow event y—tx 
connects y to define x. Particular cases are the operator ?(y) to convert an event y to a boolean data and 
the operator *(y) to convert the boolean data y to an event. We write in (A) and out(A) for the input and 
output signals of a data-flow A. 

By default, the convention of Synoptic is to synchronize the input signals of a data-flow to the parent 
trigger. It is however, possible to define alternative policies. One is to down-sample the input signals at 
the pace of the trigger. Another is to adapt or resample them at that trigger. 

3.4 Interpretation of actions 

The execution of an action A starts at an occurrence of its parent trigger and shall end before the next 
occurrence of that event. During the execution of an action, one may also wait and synchronize with 
this event by issuing a skip. A skip has no behavior but to signal the end of an instant: all the newly 
computed values of signals are flushed in memory and execution is resumed upon the next parent trigger. 
Action xl sends the signal x to its environment. Execution may continue within the same symbolic instant 
unless a second emission is performed: one shall issue a skip before that. An operation x = yfz takes the 
current value of y and z to define the new value of x by the product with /. A conditional if .xthen A elsefi 
executes A or B depending on the current value of x. 

As a result, only one new value of a variable x should at most be defined within an instant delimited 
by a start and an end or a skip. Therefore, the interpretation of an action consists of its decomposition in 
static single assignment form. To this end, we use an environment E to associate each variable with its 
definition, an expression, and a guard, that locates it (in time). 
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An action holds an internal state s that stores an integer n denoting the current portion of the actions 
that is being executed. State represents the start of the program and each n > labels a skip that 
materializes a synchronized sequence of actions. 

The interpretation [[A]]*' m ' g £ = ([P} n ,h.F of an action A (Fig. [3j> takes as parameters the state variable 
s, the state m of the current section, the guard g that leads to it, and the environment E. It returns a 
process P, the state n and guard h of its continuation, and an updated environment F. We write use|(x) 
for the expression that returns the definition of the variable x at the guard g and def| (x) for storing the 
final values of all variables x defined in E (i.e., x G y(E)) at the guard g. 

usef (x) = //x G y(E)then{{E(x))) else (((x$initO) wheng)) 

defg(£)=IL e r(£) (-* = use i0)) 

Execution is started with s = upon receipt of a trigger t. It is also resumed from a skip at s = n with a 
trigger t. Hence the signal t is synchronized to the state s of the action. The signal r is used to inform the 
parent block (an automaton) that the execution of the action has finished (it is back to its initial state 0). 
An end resets s to 0, stores all variables x defined in E with an equation x = use| (x) and finally stops (its 
returned guard is 0). A skip advances s to the next label n + 1 when it receives control upon the guard 
e and flushes the variables defined so far. It returns a new guard (s$init0) = n + 1 to resume the actions 
past it. An action x\ emits x when its guard e is true. A sequence A,B evaluates A to the process P and 
passes its state ha, guard gA, environment Ea to B. It returns P \ Q with the state, guard and environment 
of B. Similarly, a conditional evaluates A with the guard gwhenx to P and B with gwhen notx to Q. It 
returns P \ Q but with the guard gA default gs- All variables x G X, defined in both Ea and are merged 
in the environment F. 

[doAf = (((P\s"=t\r= = 0)) A)) where ((P)) nAF = [[A; end ]'M*P«o)=o),e 

[[endp n ^ E = (s = Owhengl def g (E))) o ,o,0 

[[skip]] w ' £ = ((s = n + 1 wheng | def g (£)))„ +li(( . spreO ) =n+ i). 

[ [x lf^E = {{x=lwheng))ngE 

Q* = y/zF"'^ = «-* = 4n,g,£,BK^} = ((/(use|(v),use|(z)) wheng)) 

[[A;B]]'-^ £ = ((P|e)), lfi ,, s , £fi w^((P))„ A ,, A , £A = [[Af^ E and{Q)) nM = [B]]™^ 

[[if x then A else = {P \ Q)) nB ,( gA 6^u\t gB ),(E A m B ) 

Where {P} nA , gA ,E A = [[Af"^whenusef (.v)),£ ^ ((g)}^^ = ^J^.fewhen notusef 



Figure 3: Interpretation of timed sequential actions 

In Fig. [3} we write E\±lF to merge the definitions in the environments E and F. For all variables 
x G f(E) U y(F) in the domains of E and F, 

r e(x), xeV(E)\y(F) 

(£Wf)(x)= F(x), xeV(F)\V(E) 
[ £(x)defaultF(x), ier(£)nf(F) 

Note that an action cannot be reset from the parent clock because it is not synchronized to it. A sequence 
of emissions x!;x! yields only one event along the signal x because they occur at the same (logical) time, 
as opposed to x!; skip ;x! which sends the second one during the next trigger. 
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3.5 Interpretation of automata 

An automaton describes a hierarchic structure consisting of actions that are executed upon entry in a 
state by immediate and delayed transitions. An immediate transition occurs during the period of time 
allocated to a trigger. Hence, it does not synchronize to it. Conversely, a delayed transition occurs 
upon synchronization with the next occurrence of the parent trigger event. As a result, an automaton 
is partitioned in regions. Each region corresponds to the amount of calculation that can be performed 
within the period of a trigger, starting from a given initial state. 

Notations We write — >a and -»a for the immediate and delayed transition relations of an automaton 
A. We write pred^(S') = {T\ (T,x,S) G R} and succ^ A (5') = {T\ (S,x,T) G R} (resp. pred^(5') and 
succ_» A (S)) for the predecessor and successor states of the immediate (resp. delayed) transitions — >a 
(resp. -»a) from a state S in an automaton A.Finally, we write S for the region of a state S. It is defined 
by an equivalence relation. 

VS,T£y(A), ((S,x,T)€->a)-&S = T 

For any state S of A, written S G =5^ (A), it is required that the restriction of — >a to the region 5 is acyclic. 
Notice that, still, a delayed transition may take place between two states of the same region. 

Interpretation An automaton A is interpreted by a process [[automatonxA]]' T parameterized by its 
parent trigger and reset signals. The interpretation of A defines a local state s. It is synchronized to the 
parent trigger t. It is set to 0, the initial state, upon receipt of a reset signal r and, otherwise, takes the 
previous value of s' , that denotes the next state. The interpretation of all states is performed concurrently. 

We give all states 5,- of an automaton A a unique integer label i = \Si\ and designate with [A] its 
number of states. So is the initial state and, for each state of index i, we call A, its action i and x ; y the 
guard of an immediate or delayed transition from 5; to Sj. 

[[automatonxA]] rf = 

(( (r=s\ s = (Owhenr) default (*'$init0) | {U Si e^(A) W)) AO) 

The interpretation J5,]]' s of all states < i < [A] of an automaton (Fig. [5]) is implemented by a series of 
mutually recursive equations that define the meaning of each state 5, depending on the result obtained for 
its predecessors Sj in the same region. Since a region is by definition acyclic, this system of equations 
has therefore a unique solution. 

The interpretation of state Sj starts with that of its actions A,-. An action A; defines a local state 
Si synchronized to the parent state s = i of the automaton. The automaton stutters with s' = s if the 
evaluation of the action is not finished: it is in a local state Si ^ 0. 

Interpreting the actions A, requires the definition of a guard g, and of an environment Ej. The guard 
gi defines when A, starts. It requires the local state to be or the state 5, to receive control from a 
predecessor Sj in the same region (with the guard x«). 

The environment Ei is constructed by merging these Fj returned by its immediate predecessors Sj. 
Once these parameters are defined, the interpretation of A, returns a process P, together with an exit guard 
hi and an environment Fi holding the value of all variables it defines. 

Upon evaluation of A,, delayed transition from Si are checked. This is done by the definition of a 
process <2/ which, first, checks if the guard xu of a delayed transition from 5, evaluates to true with Fi. If 
so, variables defined in f} are stored with defj^f/). 
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All delayed transitions from 5, to Sj are guarded by hj (one must have finished evaluating i before 
moving to j) and a condition gij, defined by the value of the guard Xjj. The default condition is to stay in 
the current state s while Si ^ (i.e. until mode i is terminated). 

Hence, the next state from i is defined by the equation s' = s' t . The next state equation of each state 
is composed with the other to form the product ITi< TA] s ' = s 'i tnat is merged as s' = Vi<[Al s 'i- 



Vi < \A] , iSif = (Pi | Qi | sf = when (s = i) || s' = $ /s iW here 
= [[Aif M 

Qi = Y[(Si.Xij,Sj)e^> A ( de f/i,when(use f .(A-, 7 ))(^')) 
E i= Ws^epred^ (Sj) F i 

gi = 1 when (j ! $initO = 0) default (\/ ( Sj , Xjl ^)e^ A ( use E(xji)) 
gij = hiwhen (use^^/y)), V(Si,Xij,Sj) G 

s'f = (jwhenjj / 0) default (V(j,* ; ^)e^0' when «y 



Figure 4: Recursive interpretation of a mode automaton 



4 Conclusion 

Synoptic has a formal semantics, defined in terms of the synchronous language Signal. On the one 
hand, this allows for neat integration of verification environments for ascertaining properties of the sys- 
tem under development. On the other hand, a formal semantics makes it possible to encode the meta- 
model in a proof assistant. In this sense, Synoptic will profit from the formal correctness proof and subse- 
quent certification of a code generator that is under way in the GeneAuto project. Moreover, the formal 
model of SIGNAL is the basis for the Eclipse-based polychronous modeling environment SME (3JS1- 
SME is used to transform Synoptic diagrams and generate executable C code. 
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